1. Field of the Invention
This invention relates to the field of data processing systems. More particularly, this invention relates to mechanisms for improving the security of operation of data processing systems.
2. Description of the Prior Art
Increasing the security of operation of data processing systems is becoming an important issue. As an example, a data processing system may be used to process protected data, such as copyright protected material, using digital rights management systems. Such systems may require security checking code to be executed and security checks passed before permitting further processing, such as playback of copyright material, to proceed. The security mechanisms may be password checking or license checking mechanisms. A known form of attack against such security mechanisms is to attempt to bypass the security program code, such as the password checking code, and jump into the program at a later point with a view to processing continuing as if the security check had been passed. In order to try and resist such attacks, it is known to provide mechanisms such as function gating as supported in the Intel IA32 architecture and specific entry and exit opcodes used to denote function entry and exit points. However, such mechanisms have a disadvantageous amount of additional overhead associated with them and are difficult to add to existing computer code without significant rewriting and restructuring of that code.
It is known to make published entry and exit points available at compile time across different software modules. For example, . . . “National Semiconductor NS32532-20/NS32532-25/NS32532-30 High-Performance 32-Bit Microprocessor”—May 1991 describes a system having ENTER and EXIT instructions which enable a programmer to make calls between modules, which are distinct program entities in their own right. The aim is to load modules into physical memory at addresses determined at run time, but still provide a mechanism which allows the relative addresses of functions within each module to be established at compile time. At run time the OS establishes and maintains link tables in memory, which combine runtime module location and the relative addresses of functions within a module to provide yield absolute call addresses.
VAX-11 Architecture Reference Manual EK-VAXAR-RM-001, 20 May 1982 (Revision 6.1) describes a system having procedure call instructions. Three instructions are used to implement a standard procedure calling interface. Two instructions implement the CALL to the procedure; the third implements the matching RETURN. The CALLG instruction calls a procedure with the argument list actuals in an arbitrary location. The CALLS instruction calls a procedure with the argument list actuals on the stack. Upon return after a CALLS this list is automatically removed from the stack. Both call instructions specify the address of the entry point of the procedure being called. The entry point is assumed to consist of a word termed the entry mask followed by the procedure's instructions. The procedure terminates by executing a RET instruction. The system requires the presence of the entry mask at the entry point. The entry must take place in accordance with required alignment.
The entry mask specifies the subprocedure's register use and overflow enables: e.g. a 16-bit word with bits 0-11 masking r0-r11, 12-13, 14 and 15 labeled IV and DV (integer and decimal overflow enables).
On CALL the stack is aligned to a longword boundary and the trap enables in the PSW are set to a known state to ensure consistent behavior of the called procedure. Integer overflow enable and decimal overflow enable are affected according to bits 14 and 15 of the entry mask respectively.
Floating underflow enable is cleared. The registers R11 through Rf1 specified by bits 11 through 0 respectively are saved on the stack and are restored by the RET instruction. In addition, PC, SP, FP, and AP are always preserved by the CALL instructions and restored by the RET instruction.
Budiu, Erlingsson and Abadi “Architectural Support for Software-Based Protection”, ASID'06 Oct. 21, 2006 discloses security improvements by extending CPU architectures by adding a label (cfilable), “checked jump” instructions and a new register, cfi_register. To perform a checked jump, software loads the cfi_register with the value of the label expected to be found in cfilable at the entry point to the required function subsequently called by the “checked jump” instruction. If the value in the cfi_register and cfilable are found to match during a “checked jump” then the value in cfi_register is zeroed, and execution allowed to proceed. If during a “checked jump”, the cfi_register contains a non-zero value, an exception is raised. This extends the idea of a required data tag at the call location for use in security control.
With these approaches difficulties will be encountered when one tries to integrate legacy software which has not implemented cfilable values at function entry points, with newer software which intends for them to be present. As a result, the whole of a system's software will have to be upgraded at the same time to take advantage of this new feature, which may well be infeasible—as it is possible no one single company may have access to all the required source code.